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AUTOMATED STATEMENT PRESENTATION, ADJUSTMENT 
AND PAYMENT SYSTEM AND METHOD THEREFOR 
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Th is_ a p pi i c a_ti o n j_s_based on, and _c la i ms_p_r ipr_i_ t y_ 

to, U.S. Provisional Application No. 60/161,270, entitled 
AUTOMATED STATEMENT PRESENTATION, ADJUSTMENT AND PAYMENT 
SYSTEM, filed October 25, 1999, whose contents are 
incorporated herein by reference. 



?~ BACKGROUND OF THE INVENTION 

The present invention relates to a system and method 
10 for a complete ordering to payment allocation system, and 

« in particular, to a system and method which accepts 

\7i orders from customers located at distributed locations, 

manages the ordering process by presenting a consolidated 
invoice to the seller, allows the seller to indicate 
15 which items are being paid along with a reason code for 

items for which payment is being withheld, accepts a 
consolidated payment, and allocates that payment to the 
appropriate selling subsidiary. 

As the global economy continues to flourish, 
2 0 increased demands are being placed on sellers to provide 

consolidated invoices, i.e., statements, to buying 
companies. This task is particularly difficult because 
orders from a large buying entity are typically received 
from many subsidiaries within the buying entity and from 
25 many geographically distributed locations. The buyers 
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often remit payments, or partial payments, for the 
consolidated invoice to the seller. As a result, the 
seller is unable to determine exactly which items on the 
invoice are being paid, and which items are exceptions or 
5 are in dispute. As used herein, the terms "exception" 

and "dispute" are used interchangeably"; In _ general — ■ 

exceptions and disputes differ from one another in terms 
of degree of severity, a dispute rising to the level of 
an unresolved exception which requires human 
; 10 intervention. 

1 In order to determine which items are exceptions or 

j are in dispute, a representative from the selling company 

f must contact one or more representatives of the buying 

I company in an attempt to reconcile the invoice items. 

% 15 The representatives must then work to resolve the 

i exceptions and disputes. Exceptions and disputes can 

I 

i arise, for example, when an item is not received by the 

f buyer, when the item is defective or when the item 

received is not the item which was ordered. The 
20 dispute/exception determination and resolution process 

can be time consuming, and can prevent the seller from 
properly allocating the portion of the received payment 
to the correct selling subsidiary. 

The difficulties described above are further 
25 exacerbated when the buying company's representatives are 

internationally distributed, and are ordering from 
internationally distributed selling subsidiaries. In 
this case, issues of foreign exchange further compound 
the invoicing, consolidation and payment allocation 
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processes. Current processes typically require multiple 
foreign exchanges and currency conversions. These 
foreign currency exchanges are costly, even when the 
buyer has used a credit card to pay for the ordered 
5 goods . 

ETarge "buyersT ~p"a'rt"rcui~a*rly -buyers- f rom- a- company 

which has many international locations, want to receive 
one main bill in one currency, for example, U.S. dollars, 
and regional bills for the international entities in 

10 local currencies so that the international locations know 

what their cost will be, even if the actual invoice is 
paid in the currency corresponding to the main bill. 

In addition, large companies want to effectively 
meet the regulatory requirements affecting their entities 

15 in a manner which still allows the maximization of 

profits. As such, both buyers and sellers must report 
and manage their systems and processes to satisfy local 
tax and regulatory issues. 

It should be noted that the terms "goods," 

20 "services" and "items" refer to those things ordered by a 

buyer and are used interchangeably herein. 

An example of a prior art sales system is explained 
with reference to Fig. 1. Fig. 1 is a block diagram of 
prior art sales system 2. In this type of system, buyers 

25 4 from different buyer locations 6 each individually 

order items from a seller by contacting a seller division 
8. In the case of sales system 2, different buyers, even 
from the same buying location 6, place orders directly 
with the subsidiary which will supply the item. Seller 
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divisions 8 can be geographically separated across 
international boundaries. The arrangement of sales 
system 2 makes invoice consolidation virtually 
impossible . 

5 As a result, each seller division 8 prepares a 

' ^paTate~invoi/ce~for^a^ — T-he— buye-r-4— 
at each buyer location 6 must then cull through the 
invoices, often paying each invoice separately through 
the issuance of multiple checks, wire transfers, etc. In 
: fj 10 addition, should a dispute or exception arise, buyer 4 

,fj" will typically not authorize payment for the entire 

*f! invoice until the dispute or exception can be resolved. 

^ Buyers 4 often will not make it clear which items on an 

;fl invoice are exceptions or are in dispute. Thus, the 

L 15 seller has no way to know that there is an exception or 

..y dispute until the partial payment is received. This 

prolongs the time in which the seller must wait to 
:j receive payment because the dispute/exception resolution 

process does not start until the seller receives the 
2 0 partial payment. 

Using the model of sales system 2, the process often 
implicates the seller's bank, because the bank might 
receive an electronic wire transfer or lock box payment, 
part of which is in dispute, with no way to accurately 
25 determine which seller division 8 should receive credit 

for the deposit. This situation is particularly onerous 
in the case where seller divisions 8 are distributed 
across international boundaries such that foreign 
exchange procedures must also be considered. Thus, prior 
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art sales system 2 does not allow for invoice 
consolidation, efficient invoice verification by the 
buyer, allocation of payments to the appropriate 
subsidiary and an environment where disputed payments are 
5 made known to the seller prior to receipt of the partial 

With the proliferation of global computing networks, 
such as the Internet and private networks, many sellers 
have implemented network-based ordering systems, an 

10 example of which is shown in Fig. 2 and is designated as 

ordering system 10. Systems such as ordering system 10 
facilitate the ordering and booking of buyer purchases, 
but do not solve the problems of invoice consolidation, 
order verification, exception resolution and payment 

15 processing. As shown in Fig. 2, buyers 4 at buyer 

locations 6 use network 12 to access seller web site 14. 
Network 12 is typically a private network or the 
Internet. Seller web site 14 typically runs on a 
processing server and is arranged to accept orders from 

20 customers with prearranged accounts, or from a customer 

who supplies a credit card number used to pay for the 
ordered items. Seller web site 14 then electronically 
distributes the received orders to the appropriate seller 
geography 16. Distribution is typically based on a 

25 correlation between the geography of the ordering buyer 

location 6, or the geography which can fill the order in 
the must expedient manner. 

In a typical seller web site 14, buyers are 
presented with an opportunity to browse through the 
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seller's product offerings, and can build an electronic 
list of items to be purchased, and subsequently invoiced. 
These invoices, however, are not consolidated, and are 
presented in bulk back to the original buying location 6 
5 or to the buyer's main designated location. In addition 

to~ the~ rnabi-trty-tro~ prepare -consol-i-dated- invo-i-ces^ 

systems such as ordering system 10 do not allow buyers to 
electronically verify that their orders have been 
received or to indicate the allocation of the payment to 

10 received items to facilitate the exception resolution 

process. The systems also do not allow the seller or 
seller's bank to allocate the received payment to the 
appropriate geography 16 or to transfer received funds to 
the geography's corresponding banks or bank accounts. 

15 In sum, there is no existing system which provides 

an end-to-end "quote-to-payment" system which allows a 
seller to accept and book orders, prepare a consolidated 
invoice for the buyer, allow the buyer to electronically 
view the consolidated invoice, verify those items for 

2 0 which a consolidated payment is being remitted, begin 

dispute and exception resolution procedures, receive the 
consolidated payment, allocate the payment to the 
individual subsidiaries (geographies, divisions, 
locations, etc.) and transfer funds to banks or bank 

25 accounts associated with those selling entities. 

SUMMARY OF THE INVENTION 

The present invention provides a system and method 
which allows seller to accept and book orders, allows the 
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seller to prepare a consolidated invoice for the buyer. 
The buyer is notified that the consolidated invoice is 
available and can electronically view the consolidated 
invoice, verify those items for which a consolidated 
5 payment is being remitted and begin dispute and exception 

r eso lut _ i"on*pr ocedur es- The— me t-hod -and— sys-t em— re c e-i-ve— t he— 

consolidated payment, allocate the payment to the 
individual subsidiaries (geographies, divisions, 
locations, etc.) and transfer funds to banks or bank 

10 accounts associated with those selling entities, even 

when foreign exchange is involved. Further, the present 
invention allows the seller to maximize profits by 
booking and fulfilling orders and obtaining payment in a 
form which minimizes foreign exchange exposure. 

15 The present invention provides a method for an 

ordering and payment allocation system in which one or 
more orders are received from at least one buyer, each of 
the orders corresponding to at least one seller 
subsidiary. The orders are consolidated into a 

20 consolidated invoice. The consolidated invoice is made 

available to the at least one buyer. An indication is 
received from the at least one buyer as to which of the 
orders a payment is being approved. The payment is 
allocated to a corresponding at least one seller 

2 5 subsidiary for which the payment has been made. 

As another aspect, the present invention provides an 
ordering and payment allocation system in which there is 
an order management system. The order management system: 
receives at least one order from, a buying 
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organization having at least one buyer; 

evaluates the at least one order against one or 
more criteria, orders which meet the one or more criteria 
are approved orders; 
5 books the approved orders; 

— generates -a -eonsol-idated- invoice- Abased -on- t-he 

approved orders; 

makes the consolidated invoice available to the 
buying organization; and 
10 receives an approval indication from the buying 

organization, the approval indication includes an 
identification of those booked orders for which payment 
is authorized. A funds distribution system facilitates 
the distribution of the authorized payment received from 
15 the buying organization. 

As still another aspect, the present invention 
provides an order management system which uses a 
communication network to support at least one selling 
entity and one or more unaffiliated buying organizations, 
20 the order management system in which there is a database. 

A network interface is coupled to the communication 
network. A processor executes functions which include: 

receiving at least one order from a buying 
organization having at least one buyer; 
2 5 evaluating the at least one order against one 

or more criteria, orders which meet the one or more 
criteria being approved orders; 

generating a consolidated invoice based on the 
approved orders; 
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making the consolidated invoice available to 
the buying organization; and 

receiving an approval indication from the 
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20 



25 
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buying organization, the approval indication including an 
identification those approved orders for which payment is 
-authorized-. - 

As another aspect, the present invention provides a 
method for allocating funds received from a buying 
organization in which the received funds are 
disaggregated to associate portions of the received funds 
with one or more selling sub-entities. The received 
funds are processed to update an accounts receivable 
system. Funding reports are delivered to the respective 
sub-entities. The disaggregated funds are transferred to 
financial accounts for the corresponding sub-entities. 

The present invention also provides a storage medium 
storing computer executable programmatic code for an 
order management system which, when executed, receives 
one or more orders from at least one buyer, each of the 
orders corresponding to at least one seller subsidiary. 
The orders are consolidated into a consolidated invoice. 
The consolidated invoice is- made available to the at 
least one buyer. An indication is received from the at 
least one buyer as to which of the orders a payment is 
being authorized. 

Other features and advantages of the present 
invention will become apparent from the following 
description of the invention which refers to the 
accompanying drawings . 
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BRIEF DESCRIPTION OF THE DRAWINGS 

For the purpose of illustrating the invention, there 
are shown in the drawings several forms which are 
presently preferred, it being understood, however, that 
5 the invention is not limited to the precise arrangements 

and _i ns t.r.ument a Li ties, -shown 

Fig. 1 is a block diagram of a prior art sales 
system; 

Fig. 2 is a block diagram of a prior art network - 
10 based ordering system; 

Fig. 3 is a diagram of the hardware elements of the 
system of the present invention; 

Fig. 4 is a flow chart of the overall operation of 
the present invention; 
15 Fig. 5 is a flow chart of the order entry and 

receivable booking process of the present invention; 

Fig. 6 is a diagram of the invoice consolidation and 
database update process of the present invention; 

Fig. 7 is a diagram showing the distribution of a 
2 0 consolidated invoice received by a buyer in accordance 

with the present invention; 

Fig. 8 is an example of a terminal display screen 
used to approve consolidated invoices in accordance with 
the present invention; 
25 Fig. 9 is a diagram of the process flow of the 

payment processing aspect of the present invention; and 

Fig. 10 is a flow chart of the foreign exchange 
funds allocation process of the present invention. 
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DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION 

Referring now to the figures in which like numerals 
refer to like elements, there is shown in Fig. 3 a system 
constructed in accordance with the principles of the 
5 present invention and designated generally as "18" . 

— -System- -18- -provide s- -ar-eompl-ete-enrvi-ronmen-fer -f -0-r- -fehe-— quote— 

to-payment" system, allowing a buyer to place orders, and 
have those orders managed so as to consolidate them, 
allow for verification, manage invoice disputes and 
10 receive and allocate payments to the proper selling 

entity. 

System 18 is preferably comprised of one or more 
buyer terminals 20 coupled to one or both of seller order 
management system 2 2 and service provider order 

15 management system 24 . As used herein, the term "service 

provider" refers to a third party other than the seller 
and the buyer, such as a bank or other financial 
institution which provides order management and payment 
processing services. Also coupled to communication 

20 network 12 is the seller's account receivable system 26, 

the seller's general ledger 28 and the service provider 
funds distribution system 30. Service provider funds 
distribution system 30 is further coupled to one or more 
bank accounts 32 via communication links 34. 

2 5 It should be noted that, although elements 2 0-30 are 

shown as each coupled to a single communication network 
12, this arrangement is shown merely for the convenience 
of aiding explanation of the present invention and is not 
limited to such. For example, communication network 12 
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can be the Internet or other public or private network 
comprised of multiple communication networks, coupled 
together by network firewalls or other communication 
elements. Similarly, the seller's components comprised 
5 of order management system 22, seller account receivable 

_ sys-fcem-2-6— and— se-]i 

together on the seller's communication network while the 
service provider's components comprised of service 
provider order management system 24 and service provider 

10 funds distribution system 3 0 can be coupled together on 

the service provider's network. The seller's network and 
service provider's network can be coupled together via 
appropriate communication hardware to provide access for 
buyer terminals 20. 

15 Although Fig. 3 shows a single seller order 

management system 22 and a single service provider order 
management system 24, the invention is not limit to such. 
It is contemplated that more than one seller order 
management system 2 2 and more than one service provider 

2 0 order management system 24 can be implemented within 

system 18. This is the case even where the multiple 
service provider order management systems 24 are owned 
and operated by disparate or unrelated entities. 

In addition, Fig. 3 shows bank accounts 32 coupled 

2 5 via individual communication links 34 to service provider 

funds distribution system 30. It is contemplated that 
bank accounts 32 can also be coupled to communication 
network 12, or coupled to service provider funds 
distribution system 3 0 using any known networking 
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topology and technology. 

Buyer terminals 2 0 are comprised of any computing 
platform capable of running an Internet web browser or 
similar software. Examples of suitable web browsers 
5 include MICROSOFT'S INTERNET EXPLORER and NETSCAPE'S 

COMMUNreATOR- — The- eomput-i-ng- p-latfo-rm— i-tse-l-f— for— buy e-r 

terminals 2 0 can vary depending on the needs of each 
particular buyer and can range from a desktop or laptop 
personal computer or personal digital assistant to a 

10 UNIX-based workstation. 

Buyer terminals 2 0 preferably communicate with the 
other devices in system 18 using the Transmission Control 
Protocol/Internet Protocol (TCP/IP) upon which particular 
subsets of that protocol can be used to facilitate 

15 communications. Examples include Hypertext Transfer 

Protocol (HTTP) data carrying Hypertext Markup Language 
(HTML) web pages, JAVA and Active-X applets and File 
Transfer Protocol (FTP) . Seller order management 22 and 
service provider order management system 24 are each 

20 capable of generating the HTML pages and applets, and 

communicating them to buyer terminals 20. For example, 
communication may take the form of files delivered using 
FTP in electronic data interchange (EDI) , Bank 
Administration Institute (BAI) or Extensible Markup 

25 Language (XML) formats as agreed to by the sending and 

receiving parties. 

Seller order management system 22 and service 
provider order management system 24 are comprised of one 
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or more processors coupled to one or more databases which 
support the order entry, booking, consolidation, 
verification and payment allocation processes described 
in detail below. In addition, seller order management 
5 system 22 and/or service provider management system 24 

f u r the r - compr i s e~ ~ar - network- rn te r f ace — (-no -t— shown-) — to 

couple the system to communication network 12, and 
include provisions for a web site or other technology 
which can create a network presence from which the seller 

10 can electronically offer goods or services. Technologies 

including hardware and software for establishing web 
sites such as an Internet web site are known. The 
particular components of seller order management system 
22 and service provider order management system 24 are 

15 described in detail below. 

Order management systems 22 and 24 can be comprised 
of any suitable processor arrangement designed to 
accommodate the expected number of buyers 2 0 and 
transactions for the particular system in which these 

2 0 elements will be implemented. Known software languages 

and database technologies can be used to implement the 
described processes. Databases and programmatic code on 
stored in suitable storage devices within or which have 
access to systems 22 and 24. For example, order 

25 management systems 22 and 24 can be comprised of UNIX- 

based minicomputers or mainframe computers arranged with 
a suitable database, such as database technology provided 
by the Oracle Corporation. 

Seller account receivable system 2 6 can be any known 
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accounts receivable (A/R) system ranging from small 
personal computer-based systems to large mainframe-based 
systems . A/R systems are known to those of ordinary 
skill in the art and are suitable for use as long as they 
5 are capable of interoperating with communication packages 

^ Q H> ra ^nismi-b-and--reeeive— data— aero ss- eommun-i-ea-t-ien— -network — 

12. Also, seller account receivable system 26 is not 
necessarily owned and operated by the seller. Seller 
account receivable system 2 6 can be outsourced to the 
lz z. 10 service provider or a third party. 

\j] Similarly, seller general ledger 2 8 can be any known 

general ledger accounting system suitable for use in the 

: =3 operating environment in which it is placed. Known 

general ledger systems are available which range from 

m 15 personal computer-based general ledgers to mainframe- 

LJ based general ledgers. Any such system is suitable 

provided it can interoperate with communications software 

j =j to send and receive data to other devices via 

communication network 12. 
20 Service provider funds distribution system 30 can be 

any such system known in the art which is capable of 
communicating with other financial institutions or other 
bank account processors across a network or communication 
link, for example, an automated clearing house system. 
2 5 Hardware for implementing service provider funds 

distribution systems is known to those of ordinary skill 
, in the art and are typically mainframe computers, 
-although any computing platform capable of performing 
funds distribution is suitable for use in the present 
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invention. In particular, service provider funds 
distribution system 30 executes wire transfers to bank 
accounts 32 and provides details of the wire transfers to 
the appropriate selling entity. Of course, the 
5 particular accounting details can be provided by service 

provider ~brder managemenr"systrenr 2"4~ "ox~ any-other-dev-i-ee — 
capable of communicating with the seller's computing 
systems . 

The overall operation of system 18 is described with 

10 reference to the flow chart shown in Fig. 4. Within a 

selling organization, there are traditionally three 
distinct operational working capital processes. The 
first is the sales to collections process. This process 
involves setting individual sales and collection 

15 policies, evaluating a buyer's credit, making the sale to 

the buyer, actually taking the buyer's orders, including 
shipping instructions, sending the buyer an invoice and 
booking the order, receiving and depositing the payment 
from the buyer, matching the payment to the order, 

2 0 processing exceptions and handling inquiries and 

exceptions/disputes. The second operational working 
capital process involves the actual supply chain which 
includes transporting the items, managing the materials 
associated with the items, assembling, packaging, 

25 warehousing and shipping the items. 

The third major process is buyer oriented and 
involves the process which includes purchasing to 
actually making the payment. This process includes 
setting buying policies, selecting a seller, ordering the 
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items, receiving an invoice from the seller, approving 
payment, transmitting payment instructions to a financial 
institution, actually paying the invoice, reporting and 
reconciling the payments made with the items received, 
5 and addressing inquiries and exceptions/disputes. The 

pre sent —rnve-nti on-rncorporat e s -a spec t-s— of- all- -th-re e 

operational working capital processes,, but primarily 
encompasses the sales to collection and purchasing to 
payments processes . 

10 It should be noted that, although the present 

invention is described using corporate, i.e., divisional 
boundaries, the invention is not limited to such. Any 
business, legal or geographical arrangement can be 
supported using the present invention. For example, 

15 regulatory and legal issues surrounding maximization of 

profit and minimization of expenses such as taxes and 
fees are another appropriate entity/subsidiary 
arrangement. As such, a subsidiary can include 
affiliates, branches, joint ventures and the like. 

2 0 The present invention, therefore, can be used by 

sellers to efficiently consolidate and supply orders in a 
manner which maximizes profits and minimizes fees and 
taxes while meeting government regulations. In other 
words, it is contemplated that order flow can be managed 

25 based on seller's production facilities without regard to 

geography so as to ensure that tax and regulatory issues 
are not negatively impacted. As part of the same 
concept, the method and system of the present invention 
can be used to manage foreign exchange (f/x) exposure and 
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transaction costs, allowing for the maximization of 
profits. In part, this is accomplished by obviating the 
need to convert to a base currency such as U.S. dollars. 
For example, it may be more cost effective and prudent 
5 from a regulatory sense to convert from Euros to Mexican 

" ~ ~~ ~P^s~o~s~~t~ha~t "fronrEuras- to— Doli-axs- -to— Pesos-: — 

Turning now to Fig. 4, a buyer using buyer terminal 
20 enters an order. The order is entered on seller order 
management system 2 0 or service provider order management 

10 system 24 and the receivable booked (step 36) . In the 

case where the order is received by service provider 
order management system 24, order management system 24 
communicates the booked order to the seller, for example, 
to seller order management system 22. Booked orders are 

15 accumulated for a predetermined period of time, for 

example, monthly, and the associated invoices are 
consolidated and the database on service provider order 
management system 24 is updated to reflect the 
consolidated invoice and its supporting details (step 

20 38) . During the invoice consolidation and database 

update step, a unique reference number is assigned to the 
consolidated invoice for tracking and invoice management 
purposes . 

It should be noted that the present invention is not 
25 limited to invoice generation based on shipped orders. 

The present invention facilitates the separation of order 
fulfillment from invoicing. Once an order is booked, the 
present invention can generate an invoice without 
requiring that the order actually be shipped or received 
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by the purchaser. This is because the invoice 
consolidation process does not rely on product receipt 
acknowledgment as a condition of invoice generation. 

The consolidated invoice includes totals for each 
5 invoice for that predetermined period, along with a total 

— a-moun-t . The -eonsoi-i-da-ted— i-nvo-iee-r -aiong- with- the — — — 

specific details for each invoice within the consolidated 
invoice are sent by service provider order management 
system 24 (or seller order management system 22) to one 

10 or more designated buyer terminals 20, but preferably, to 

a single designated buyer terminal 20 (step 40) such as 
the accounts payable manager's terminal. Individual 
buyers associated with each invoice can then access their 
particular invoice or invoices and approve all or a part 

15 of those invoices which are their responsibility (step 

42). As described in detail below, an embodiment of the 
present invention allows buyers to initiate payment by 
selecting an appropriate box, button, etc. from the same 
display screen in which the payment amount, 

2 0 disputed/excepted items are presented and entered. Those 

individual items which are not approved are set aside for 
exception resolution . 

The approved consolidated invoice or a part thereof 
. is transmitted back to service provider order management 

25 system 24, thereby informing the seller as to exactly 

which invoice components are approved and being paid for, 
and exactly which items are exceptions or are in dispute. 
This occurs prior to, or commensurate with, the actual 
payment, thereby allowing the seller an opportunity to 
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begin exception/dispute resolution processing with 
particular knowledge of those disputed items. 

Finally, the buyer remits payments to the seller, 
preferably as a single payment via lock box, wire 
transfer, automated clearing house or foreign exchange 

—trade-: — This— payment -d-s—fehen- processed- -(-step- -4-4-) — to 

unconsolidate the payment to reflect those particular 
items for which the payment is to be applied. The 
unconsolidated payment data is communicated to service 
provider funds distribution system 3 0. which then 
transfers funds corresponding to the paid items to bank 
accounts 32 associated with the subsidiary who booked the 
particular order. 

The process of the present invention as implemented 
on system 18 allows end-to-end order to payment 
allocation processing by a seller, and allows the seller 
to meet the business needs of buyers, especially large 
buyers, by providing a mechanism for consolidated 
invoicing and exception resolution. The overall hardware 
arrangement and process having been explained, each of 
steps 36-44 will now be explained in detail. 

The order entry and receivable booking process of 
step 32 is explained in detail with reference to the flow 
chart of Fig. 5. At the beginning of the process, a 
buyer 4 places an order with the seller for a particular 
item or items (step 46) . Buyer 4 can place the order 
using buyer terminal 2 0 by placing the order directly 
through seller web site 14 using communication network 
12. In this case, seller web site 14 can be created 
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using known web site electronic commerce techniques. The 
buyer can also place the order by traditional means such 
as phone, fax and mail via a customer service 
representative who enters the order into order management 
5 system 22 or 24. As another alternative, electronic 

orders— can- be- manua-l r l-y--ente-red— §-rom-trad-i- t-i-enai -pu-reha-se — 

requisitions. In sum, it is contemplated that any of a 
number of different types of methods can be used to enter 
an order, provided that order is eventually converted 
: ' : !f. 10 into an electronic order within order management system 

Lfl 22 or 24 . 

It should be noted that, although large customers 
; =3 typically prefer invoicing, small buyers, such as buyers 

;;□ from small companies or individuals may supply payment 

I ^ 15 information in the form of a credit card number, e-cash, 

. LJ etc. at the time the order is placed. Unless otherwise 

i!5 noted, the operation of the present invention for large 

! =£ buyers and small buyers is the same. 

One difference of note is that with a large company, 

! 20 seller web site 14 and/or order management system 22 or 

i 

j 24 may be configured to offer preferential pricing and 

offers to large buyers. In addition, large companies may 
also be offered dedicated web pages on seller web site 14 
which are directed solely to the large company's 
2 5 interests. For example, a dedicated web page may include 

customized products, or products known by the seller to 
be desired by the buyer's company. On the other hand, 
smaller companies may not receive preferential pricing 
and may be forced to use a non- customized generic 
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interface on seller web site 14. 

Once the orders are received, order management 
system 22 or 24 evaluates the orders to make sure that 
they are complete and also preferably measures the 
5 purchase order amounts against the buying company's 

"avarirlakrle -credit- -a-nd/or— the— i-ndiv-i-dua-l— buyer^-s— spending — 
limit (step 48) . For example, a buyer company's 
available credit may be measured with respect to each 
particular selling entity as well as the selling parent. 
10 An individual buyer's spending limit can be measured 

against each buyer's maximum order total or individual 
item price. 

Buyers are notified if their order is not approved 
(step 50) through the receipt of a rejection message sent 

15 by order management system 22 or 24 (step 52) . The 

rejection message can be in the form of a web page sent 
to buyer terminal 20, an electronic mail message, or even 
a notification to the seller's customer service 
representative who then notifies the buyer that the order 

20 has been rejected. 

In the case where the order has been approved, and 
where the order was originated by seller order management 
system 22, the seller books the approved order (step 54) 
and creates account receivable entries in seller account 

25 receivable system 26. In the case where the service 

provider is acting as the order entry point via service 
provider order management system 24, the service provider 
sends a notification to the seller, preferably by using a 
file transmitted to seller order management system 22 



00429799.2 




- 23 - 



across communication network 12, that the orders have 
been approved and that the orders should be booked (step 
54) . 

The seller then creates appropriate A/R entries in 
5 seller account receivable system 26 and notifies the 

— appropriate -^seiti-ng— ent it-y- -or^-ent-it ies— to--f-ul-f-i-l-l--t-he"— — 

order . For example, selling organizations in 
manufacturing industries will interface to the own supply 
chains to begin the process of creating the product to 

10 fill the orders placed. Orders for services will be 

directed to the appropriate providers within the selling 
organization. Optionally, a seller may wish to execute 
off-balance sheet processes (step 56) . For example, a 
seller may wish to finance its receivables through off- 

15 balance sheet financing. In this case, the service 

provider may offer the selling organization the option to 
securitize its receivables through a securitization 
program. Securitization methods are known to those of 
ordinary skill in the art and are typically determined 

2 0 based upon the quality and quantity of the orders 

received from the buyers . 

The invoice consolidation and database update 
process of step 38 is explained with reference to the 
process flow diagram in Fig. 6. As shown in Fig. 6, 

25 divisional (subsidiary) invoices 58 are subject to an 

invoice consolidation process 60 which are then stored as 
consolidated invoices in consolidated invoices database 
62. Divisional invoices 58, invoice consolidation 
process 60 and the consolidated invoices database 62 can 
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be received, processed and stored on seller order 
management system 22 or service provider order management 
system 24 . 

Divisional invoices 58 are invoices associated with 
5 the booked orders which have been sent to each selling 

_ — .^ n ^i^y_„^ e ^p^ 0€:e . ss i n g m — i-n-vo-i-se- eonso-l-i-da-t-ion- -p-r©ees-s— 6 CD- 
involves correlating all of the divisional invoices 58 by 
sorting and compiling the invoices to create a single 
consolidated invoice, along with the details supporting 

10 each specific divisional invoice 58. Consolidated 

invoices can be arranged in any manner as discussed 
above. Techniques for manipulating a database to create 
a consolidated invoice, for example a database record or 
table comprising consolidated invoice data are known. 

15 Once consolidated invoices have been created and 

stored in consolidated invoices database 62, the master 
invoice database must be updated via update master 
invoice database process 64 . In the case where the 
consolidated invoices database 62 is present on seller 

20 order management system 22, update process 64 involves 

transmitting the consolidated invoice data across 
communication network 12 to service provider order 
management system 24, the repository for the invoice 
master database. 

2 5 Databases 66 are part of service provide order 

management system 24 and comprise division profiles 
database 68, invoice master database 70 and payment 
master database 72. The actual consolidated invoices 
which are sent to the buyer are preferably generated from 
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the service provider order management system 24, and not 
seller order management system 22. 

In addition, service terminal 74 is coupled to 
seller's A/R system 26 or service provider order 
5 management system 24 to perform manual updates, 

maintenance- -and -o t-her-ope-r a t-ions- -on— database s -6 6— a-nd— the 

processors associated with service provider order 
management system 24. Service terminal 74 can also be 
used to manually allocate funds for unmatched payments, 
10 modify invoice details, maintain subsidiary profiles, 

approve funds distributions, generate reports such as 
aging reports and paid and unpaid reports. Service 
terminal 74 accesses database 66 via communication link 
76. Communication link 76 can be any known local or wide 
15 area communication facility, and can even be a 

communication link which allows service terminal 74 to be 
remote from service provider order management system 24 
and accessed via communication network 12 . 

In order to properly track the invoices associated 
20 with the consolidated invoice, and to be able to allocate 

received payments against the individual items, databases 
68-72 are configured to store different types of data 
associated with the overall quote-to-payment system. 

Division profiles database 68 stores data relating 
25 to each selling entity. This is particularly useful in 

the case where subsidiaries (divisions) are 
international. A typical division profile record 
comprises : 

© identification code; 
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o 



o 



subsidiary name; 
subsidiary address; 



o 



o 



subsidiary contact individual; 
subsidiary bank SWIFT code or ABA RTN; 



o 



subsidiary bank account reference; and 



10 



15 



20 



25 
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o sel-ler-'-s-generarl— l-edge3r~-aceou-n-t— number^ — 

The subsidiary identification code is a unique 
number assigned to that particular selling entity. 
Subsidiary name address and contact name provide other 
means for identifying the subsidiary. The subsidiary 
bank SWIFT (Society for Worldwide Interbank Financial 
Telecommunications) code or ABA RTN (American Bankers 
Association Transit Routing Number) allows service 
provider order management system 24 to properly instruct 
service provider funds distribution system 3 0 as to where 
their allocated payments should be wired. SWIFT is a 
known international system for the transmission of bank- 
to-bank messages in which each currency has a unique 
SWIFT currency code and each bank has a unique SWIFT 
address. ABA TRN refers to the magnetic ink character 
recognition (MICR) line field which includes an 
identification number for the institution housing the 
payor's account. The seller's general ledger account 
number refers to the identification number defining the 
account number to which entries corresponding to the 
subsidiary profile are made. 

Master invoice 70 is preferably arranged to comprise 
two major components, the consolidated invoice data and 
supporting sub- invoice data. 
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The consolidated invoice records typically include: 

o invoice date; 

o customer reference; 

o consolidated invoice reference number; 
5 o total invoice amount; 

_._ o in voi-ce— amount -pa-id-; - 

o invoice adjustment amount; 
o invoice amount outstanding; and 
o invoice amount distributed. 
10 The invoice date refers to the date the consolidated 

invoice was prepared, the customer reference number 
refers to a unique identification number for the overall 
buyer, the consolidated invoice reference number which is 
created by service provider order management system 24 to 
15 track the overall consolidated invoice. The invoice 

amount reflects the total remittance by the buyer as 
applied to that invoice. The invoice adjustment amount 
reflects the amount which is deducted from the invoice or 
invoice line item prior to executing approval to pay or 
20 payment itself, i.e., the exception or disputed amount, 

if any. The invoice amount outstanding reflects the 
total unpaid amount for the consolidated invoice, and the 
invoice amount distributed reflects the total amount of 
the consolidated invoice which has been allocated and 
25 wired to the selling entities. 

The second major component of the master invoice 
database is the sub-invoice component. The sub-invoice 
component provides the particularized details behind each 
consolidated invoice. Sub- invoice record fields include: 
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o 



subsidiary code; 



o 



invoice reference ; 



o 



i nvo ice amount ; 



o 



invoice amount paid; 



o 



invoice adjustment amount; 



-O 



in-voiee -ameu-n-t— outstanding-; — and-—— 



o 



invoice amount distributed. 



10 



15 



20 



Many of these fields are the same as those described 
above with respect to the division profile database and 
consolidated invoice component of the master invoice 
database, with the exception that these fields reflect 
sub-invoice, i.e., non-consolidated individual invoice, 
amounts. For example, an invoice directed to purchases 
by buyer A would be reflected on a sub- invoice record, as 
would an invoice directed to buyer B. The consolidation 
of the buyer A and buyer B invoices are reflected in a 
consolidated invoice record. 

Payment master database 72, payment processing 
procedure (step 44) and the distribute disaggregated 
funds process 80 are discussed in detail below with 
respect to the funds distribution aspect of the present 
invention. In sum, the invoice consolidation and 
database update processes of step 3 8 result in the 
consolidation of individual divisional invoices 58, and 
appropriate databases 66 updated to reflect the 
consolidated invoices and the sub-invoices comprising the 
consolidated invoice for subsequent invoice verification 
and payment processing. 

It should be noted that the present invention can 
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accommodate multiple sellers supported by one or more 
service provider systems. For example, a service 
provider may use only a single provider order management 
system 24 to accommodate multiple sellers. As such, it 
5 is preferable to store invoice data and other data in 
^.g.^.^.g.g^.g _g_g_ j^.-g. -f- or ma £ — c 0 mmo rt -to — a-H.— s e ii e r s 

accommodated by system 18. However, because it may be 
impractical to employ a common format, it is contemplated 
that more than one format can be used and like sellers 

10 grouped to use a particular format. Data received by a 

seller, for example from seller order management system 
22 or from buyer terminals 20, must therefore be 
converted to a format, i.e., record lengths, types, etc., 
consistent with databases 66. 

15 In that regard, the service provider preferably 

provides the seller with the desired record formats so 
that the data transmitted to service provider order 
management system 24 is in the proper format. In the 
alternative, the service provider can develop custom 

20 conversion processing routines for each seller and can 

implement these conversion processes on service provider 
order management system 24 or another processor which has 
direct or indirect access to databases 66. 

Eventually, it becomes time for the seller to send 

2 5 the consolidated invoice to the buyer. Any method for 

transmitting the consolidated invoice to the designated 
buyer representative, for example, the accounts payable 
manager at the buying company is acceptable. Preferably, 
one of three transmission methods are used. First, the 
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service provider can present the consolidated statement ■ 
on-line to the buyer by making that statement available 
on service provider order management system 24 in a 
format suitable for viewing and approving via a buyer 
5 terminal 20. This process may be initiated, for example, 

by^n— eiec t rorri-c -mai-3r-o-r-ot-her— message— fe©-febe-a€€0u-nfe s 

payable manager indicating that a consolidated statement 
is available for processing. As for the second method, 
the service provider can prepare and distribute paper 

10 statements to the accounts payable manager at the buyer's 

location. Third, the service provider can push the 
invoice to buyer terminal 20 using a file delivery 
mechanism such as the File Transfer Protocol (FTP) . 
In addition, the accounts payable manager can 

15 optionally download the detailed sub- invoice data for 

subsequent distribution to the individual buyers 
responsible for the corresponding sub-invoice. An 
example of the invoice distribution process of step 40 is 
described with respect to the block diagram in Fig. 7. 

2 0 As shown in Fig. 7, an accounts payable manager 82 

receives consolidated invoice 84. Consolidated invoice 
84 includes the name of the selling company 86, a 
statement title 88 and consolidated invoice reference 
number 90. Consolidated invoice 84 also comprises sub- 

25 invoice data 92 reflecting the sub-invoice title and 

total sub-invoice amount. Consolidated invoice 84 also 
includes a consolidated invoice total 94. 

Accounts payable manager 82 then distributes the 
■ sub- invoice data to buyer 4 responsible for that sub- 
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invoice. As shown in Fig. 7, sub- invoice 96, sub- invoice 
98 and sub- invoice 100 have been distributed to buyers 4, 
respectively J. Smith, B. Jones and R. Stevens. 

As is shown in Fig. 7, sub-invoices 96, 98 and 100 
5 each include a sub-invoice detail area 102 and sub- 

i-nvoi-ee- -t-ofcai— -1*0 4--. — S-u-b~ iiwoi-ee- deta-i-1— a-^ 

the corresponding buyer to scrutinize each individual 
item within the sub- invoice to determine whether to 
authorize payment for that particular item. Buyer 4 uses 

10 whatever internal processes are available within the 

buying company to notify accounts payable manager 82 as 
to whether there are any exceptions or disputed items, 
preferably along with the relevant reason codes 
explaining why the payment for the corresponding item is 

15 being disputed, which items they are, and also the amount 

to include from their sub- invoice in the total 
consolidated payment to the seller. 

The invoice approval step (step 42) will now be 
explained in detail with reference to the buyer terminal 

20 20 display screen shown in Fig. 8. As discussed above, 

accounts payable manager 82 is notified or sent details 
regarding consolidated monthly statement via a 
consolidated monthly statement 84. Accounts payable 
manager 82, or any other authorized individual within the 

2 5 buying company, can use buyer terminal 2 0 to access 

service provider order management system 24 to actually 
approve the invoices corresponding to consolidated 
invoice 84. It should be noted that, in the case where 
accounts payable manager 82 accesses service provider 
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order management system 24 to initially receive the 
consolidated invoice, the display screen shown in Fig. 8 
corresponds to consolidated invoice 84. Consolidated 
invoice display screen 106 is preferably comprised of 
5 HTML data transmitted from service provider order 

management— system- -2-4— te--buye-2~ t^e-rmi-nai— ^ 2-Q-v-i-a 

communication network 12. It is also contemplated that 
the HTML data can be exported to an enterprise resource 
planner such as those offered by PEOPLESOFT, SAP, and the 

10 like. 

Consolidated invoice display screen 106 includes 
title 108, client identifier 110, consolidated statement 
reference number 112, invoice payment indicators 114, 
sub-invoice totals 116, invoice payment amount entry 

15 areas 118, code entry areas 12 0, approval button 122 and 

pay button 124 . 

Invoice payment indicators 114 are selected by the 
accounts payable manager to indicate that the 
corresponding invoice is to have some amount paid toward 

20 it. Invoice payment indicators 114 can be implemented as 

radio buttons, check boxes, or any other suitable browser 
or graphical user interface mechanism. Sub- invoice 
totals 116 reflect the total sub-invoice amounts for each 
corresponding sub-invoice. Invoice payment amount entry 

2 5 areas 118 are completed by accounts payable manager 82 in 

accordance with the actual amount the buyer is willing to 
pay against the corresponding invoice. Code entry area 
12 0 provides a mechanism by which accounts payable 
manager 82 can indicate to the seller specific reasons 
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for the payment. The actual codes can be customized for 
each buyer or seller to provide particularized details 
regarding order discrepancies, quality, 
exception/ disputes , etc . 
5 For example, as shown in consolidated invoice 

- — di-spi-ay -sereen- -H) 6-7 — aeeeu-n-ts-p>ay-a-bie— ma-nag er^-8-2— -i-s- — — 

authorizing some payment for each of invoices X, Y and Z 
by selecting invoice payment indicators 114 for each of 
those invoices. Accounts payable manager 82 is 

10 authorizing the entire $3,000 to be applied to invoice X, 

the entire $5,000 in payment for invoice Z, but only 
$2,000 in payment for invoice Y, for a total payment 
against this consolidated invoice of $10,000 as shown in 
consolidated invoice total payment entry area 126. The 

15 accounts payable manager 82 can either indicate an 

approval to authorize subsequent payment of the amount 
shown in consolidated invoice total payment entry area 
126 by selecting approval button 122, or can approve and 
authorize payment of the amount entered in area 12 6 by 

20 selecting pay button 124. 

Selecting pay button 124 automatically causes the 
buyer's bank to remit payment to the seller's service 
provider, while selecting approval button 122 indicates 
to the seller that the amount in area 12 6 has been 

25 approved and that the seller can expect to receive 

payment in some form. In other 'words, selecting pay 
button 124 authorizes the service provider to receive 
payment instructions from the buyer, preferably via 
communication network 12 through a secured link, and to 
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collect funds on the seller's behalf. Although any 
method of remitting a payment is acceptable, preferable 
methods include remittance via ACH, wire or even a 
"cutting" and sending a check off-line. 

At this point, the buying company has received and 
"reviewed— the - consolrf dated— and— sub --invoices-, — ha-s— i-ndi-ea-ted- 
which items are being paid, indicated which sub- invoices 
contain a disputed amount, and preferably provided a code 
in code entry area 120, and either approved the 'invoice 
or authorized electronic payment of the consolidated 
invoice total payment amount. 

The funds receipt and payment processing procedures 
of step 44 are explained in detail with respect to Fig. 
9. Fig. 9 is a process flow diagram of the payment 
processing portion of the present invention. In general, 
a buyer can remit payment to the seller in any known 
fashion. Preferably, payments are made in the form of a 
lock box payment 12 8, a wire transfer 13 0, an automated 
clearing house (ACH) payment 132, or a foreign exchange 
trade 134. Payments can also be made using any 
acceptable payment method, including electronic cash and 
cash equivalents, netting via the Internet and electronic 
wallet technologies. Data relating to the payment is 
typically received by service provider funds distribution 
system 30, service provider order management system 24 or 
seller accounts receivable system 26 (as is typically the 
case with ACH and lock box payments 132 and 13 8, 
respectively) . The seller preferably receives payments 
which include the assigned reference number corresponding 
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to the adjusted consolidated monthly statement total 126. 

Upon receiving a payment, payment master database 72 
is updated, and this data made available to service 
provider funds distribution system 30. Payment master 
database 72 contains payment records which preferably 
-±nc±ud'ei — — 



o payment date; 

o payment method; 

o payment reference; 
10 o payment amount; 

o from currency; 

o to currency; 

o f/x, tax and fee data; 

o distribution status; and 
15 o amount distributed. 

The payment method refers to whether the payment was 
received as a lock box payment 128, wire transfer 130, 
ACH payment 132 or foreign exchange trade payment 134. 
The payment reference refers to the consolidated invoice 
20 payment reference number (shown on consolidated invoice 

84 as consolidated statement reference 90) . From and to 
currency refer to the origination and destination 
currencies in the case where payment is being made via 
f/x in a currency different that the currency used by the 
25 seller, for example, Mexican Pesos and British Pounds. 

F/x, tax and fee data refer government charges and fees 
imposed by international financial institutions to pass 
funds to a third party. Distribution status indicates 
whether the seller subsidiary has received no 
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distribution, a partial distribution (such as when a sub- 
invoice contains exceptions or disputed payments) , a full 
distribution net proceeds from a credit card settlement 
or f/x. Finally, the amount distributed is also stored 
5 in payment master database 72. Of course, the 
— — d ;rs tribu : ti-on— stra :t us^ -and— the—amount- -et± s tr^ibu^b ed- -f-i-e 1-ds- -are- 
updated at such time as distribution is made. 

A number of options for processing the payment are 
preferably provided, each method providing an increased 

10 level of service and processing for the seller. As the 

lowest level of service, lock box payments 128 (or wire 
transfers 130, ACH payments 132 or foreign exchange 
trades 134) can be processed by service provider funds 
distribution system 3 0 to interface with and update 

15 seller A/R system 26. This process is shown as link 136. 

The process of updating seller A/R system 26 at this 
lowest level of service entails "manually" updating 
seller A/R system 26. As such, the relevant data is key- 
entered by hand by the service provider, for example, the 

2 0 lockbox provider. The file sent from the service 

provider is preferably an electronic transmission 
directly to seller A/R system 26. 

The manual process is typically used when the 
buyer's accounts payable manager does not use the 

25 electronic, web-based receivables process described 

above, and instead opts to make adjustments to the 
consolidated statement, for example, by marking up a 
paper copy, which is then received by the service 
provider. Update process 13 8 involves informing the 
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seller of exactly which receivables have been paid by the 
buyer and which receivables are still exceptions or are 
in dispute. This can be accomplished via an electronic 
file transfer, electronic mail, paper and the like. The 
5 manual method shown by link 13 6 is the most labor - 

ifrt'eTrsTVe7~be'cause- the— information -received— f-rom— t-he 

buyer's accounts payable manager may not sufficiently 
explain or identify the exceptions and disputed items. 

The next level of payment processing is one in which 

10 the service provider performs a consolidated receivables 

process 140. Under process 140, the service provider 
merges the remittance information on the client access 
information reporting engine and delivers a final report 
to the seller by electronic mail, paper, wire transfer, 

15 etc. Update process 138 for updating seller's A/R system 

26 is then performed as described above. 

Under consolidated receivables process 140, all 
incoming payment data directed to a particular seller are 
gathered into a single report for that seller to use to 

20 update their seller A/R system 26. The payment data can 

be received from other service providers, for example, 
other banks, as well as the buyers themselves. 

The next most detailed level of payment processing 
service from the service provider's perspective is one in 

25 which match receivables process 142 is performed in 

addition to consolidate receivables process 140. As part 
of match receivables process 142, the seller applies the 
resultant consolidated receivables data to the seller's 
file of outstanding sub-invoices. The file containing 
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the matching data is then sent to, or made available to, 
the seller in any manner described above with respect to 
update process 138. As part of the matching process, it 
is necessary to access invoice master database 70 and 
5 payment master database 72 . 

- — ■ The— mos fc— de-fca-i 1-ed— 1-e ve 1—o-f— paymen-fer-proc e ss-i-ng — 

contemplated as part of the present invention is complete 
A/R processing 144 . Complete A/R processing 144 is 
substantially the equivalent of complete accounts 

10 receivable outsourcing provided by the service provider. 

As part of A/R processing 144, the service provider 
maintains the client's receivables database in service 
provider order management system 24, service provider 
funds distribution system 3 0 or another system configured 

15 to perform this function. A/R processing 144 receives 

the results of match receivables process 142, applies the 
consolidated and matched receivables data to create A/R 
and general ledger update data, and also updates the 
seller's general ledger 28 via update process 146. This 

2 0 process is preferably performed via communication network 

12. Under A/R processing 144, the process of updating 
the seller's A/R system as shown in process 138 is 
incorporated therein. This is the case because the 
seller typically has control of, or access to, seller A/R 

25 system 26. 

Once the seller's A/R system has been updated as 
_ shown in process 138, the seller has enough information 
to engage in exception management and dispute resolution, 
as shown by exception management and dispute resolution 



00429799.2 



- 39 - 

! 

j process 148. Methods for resolving exceptions and 

I 

I disputes are discussed above. As exceptions and disputes 

are resolved, and payments are made, written-off, or 
! otherwise promised by or to the seller, the seller's A/R 

5 system is updated to reflect the results of exception 

, manag.ement_and_di.sput e— resolution-, Du-ring—e^a-f-te-r 

exception management and dispute resolution process 148, 
funds which were disaggregated during the consolidate 
receivables process 140, match receivables process 142 
! =3. 10 and A/R processing 144 to properly apply a payment to a 

!.f| sub- invoice item can be reported to, and distributed to, 

;^ the appropriate seller subsidiary. 

Q Distribution of disaggregated funds process 80 is 

rfi comprised of two main components. The first involves 

; ;_ 15 delivering funding reports to seller's subsidiaries, 

LJ shown as process 150. The second is the actual wiring of 

funds to the seller's subsidiaries' bank accounts, shown 
□ as process 152 . 

Funding reports are preferably generated by service 
20 provider funds distribution system 30 in conjunction with 

data retrieved from databases 66. In particular, payment 
master database 72 is updated to reflect the distribution 
status and amount distributed, and a report is generated 
by service provider funds distribution system 30 or 
2 5 service provider order management system 24 and 

communicated to the seller's subsidiary. This report 
preferably comprises a detailed accounting of which 
particular sub-invoice items are included in the 
distribution, along with any other such detail as is 
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necessary. Other details may include payment date, 
results of exception management and dispute resolution 
processing, relevant sub-invoice details and reason 
codes. In other words, reports can include any element 
5 stored in databases 66, including status and aging data. 

_ The— actual— funds—whi-ch— are-accounted— for- -i-n— the — 

funding report are wired or transferred using any 
suitable means, to the seller's subsidiaries' bank 
accounts shown in process 152. The present invention 

10 therefore accommodates an entire quote to payment system 

which allows a buyer to conveniently enter orders, 
informs the seller as to any items which are exceptions 
or are in dispute, and allows a service provider to 
create a consolidated invoice, receive a payment and 

15 unconsolidate the payment in order to disaggregate the 

funds, update seller's accounts receivable system and 
optionally the seller's general ledger system, and 
distribute the disaggregated funds to the seller's 
subsidiaries . 

2 0 As part of payment processing procedure step 44, 

funds may be received and processed in one country, for 
example, the United States, but allocated to a seller 
subsidiary abroad, for example, in England. Because it 
is costly to execute multiple foreign exchange trades, 

25 the present invention advantageously provides a mechanism 

Tor . allocating funds destined for seller's subsidiaries 
which operate under a different currency until a 
predetermined total is reached. This avoids the need to 
make multiple foreign exchange transfers to these 
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countries . 

The foreign exchange funds allocation process is 
explained with reference to the flow chart in Fig. 10. 
Initially, an incremental funding amount is determined 
(step 154) . The incremental funding amount is typically 

-de t er mi ne d_i~n— p r o c esse s- 14-0—1-44-,- -or^-a£t er— the— fund -ing 

report is generated during distribute disaggregated funds 
process 80. If the addition of the incremental funding 
amount with a aggregated funding holding account balance 
amount equals or exceeds a predetermined total (step 
156) , then the transfer is affected and funding 
accomplished via foreign exchange trade (step 158) . The 
total aggregated funding can be stored in any of the 
service provider's (or seller's) systems, but is 
preferably maintained in service provider funds 
distribution system 30. If the incremental funding 
amount does not result in a predetermined total being 
reached, the incremental funding amount is allocated into 
a holding account (step 160) as discussed above. In this 
manner, the present invention allows for efficient 
foreign exchange activity. 

Although the present invention has been described in 
relation to particular embodiments thereof, many other 
variations and modifications and other uses will become 
apparent to those skilled in the art. It is preferred, 
therefore, that the present invention be limited not by 
the specific disclosure herein, but only by the appended 
claims . 



